home *** CD-ROM | disk | FTP | other *** search
/ Freaks Macintosh Archive / Freaks Macintosh Archive.bin / Freaks Macintosh Archives / Ham⁄GPS / IP Folder / HAMradio TCP⁄IP / Docs / SLFP Info < prev   
Internet Message Format  |  1993-01-04  |  8KB
  1. From: Dewayne Hendricks WA8DZP
  2. To:   Users of NET/Mac 2.3.15 (and higher versions)
  3.  
  4. Here is the documentation on SLFP.
  5.  
  6. I tested SLFP with the following attach command:
  7.  
  8. # Setup the SLFP Support
  9. attach asy 2 a slfp sf0 8092 1152 2400 atdt1,2346-6789
  10.  
  11.  
  12. ==================================================================
  13.  
  14.  
  15.  
  16.  
  17.      MNET:MIT.SLFP               Last updated: 10 November 1987
  18.      
  19.      This file contains technical documentation of the MIT Serial Line
  20.      Framing Protocol, as implemented in the Merit Computer Network.
  21.      It was retyped from the original information from MIT on 11/10/87.
  22.     
  23.                 Appendix I:  Serial line Framing Protocol
  24.      
  25.           (This description is from a very old file written  when  we
  26.      were   first  implementing  the  protocol.   Details  are  still
  27.      accurate, though.)
  28.      
  29.           This  is  preliminary  documentation  on  the  serial  line
  30.      protocol  used  between  the  IBM  PCs  and the PC Gateway.  The
  31.      protocol has two levels: the low-level protocol  (LLP)  and  the
  32.      local  net  protocol.  The low level protocol wraps a packet and
  33.      delivers it to the PC Gateway.  The local net protocol tells the
  34.      PC Gateway what kind of packet it is.  Currently there two types
  35.      of packets: Internet and Address Request.  When the  PC  Gateway
  36.      receives  an  Internet  packet,  its  action  is  to forward the
  37.      internet packet  to  a  process  which  checks  the  packet  for
  38.      validity and then sends it to the net.  On receipt of an Address
  39.      Request  packet,  the PC Gateway sends an Address Request packet
  40.      back to the PC with  four  bytes  of  data  (the  PC's  internet
  41.      address) in the body of the packet.
  42.      
  43.           Neither  the  LLP  nor  the  local net protocol provide for
  44.      prioritized transmissions, checksums or  complex  line  control.
  45.      They  are  merely  a  simple  way  to  get  packets  to and from
  46.      machines.
  47.      
  48.           The local net protocol consists of a four byte leader.  For
  49.      an internet packet, this leader is:  2,1,0.0.   For  an  Address
  50.      Request, the leader is 2,3,0.0.  There is no data in the Address
  51.      Request  packet sent from the PC; it is only the four byte local
  52.      net header wrapped in the serial line protocol.
  53.      
  54.           The receipt of any packet with a local net header that does
  55.      not identify the packet as either internet or address request is
  56.      an error and the receipt of such a packet should be  logged  and
  57.      the packet discarded.
  58.      
  59.           LLP  consists  of  four  bytes  with  special meanings when
  60.      received over the serial line.  These are: ESC,  REQ,  ACK,  and
  61.      END.
  62.      
  63.           A packet is enclosed in a REQ and an END.  When a PC wishes
  64.      to  send  a  packet  it first sends a REQ to the PC Gateway.  It
  65.      then waits a suitable length of time to receive an ACK from  the
  66.      PC  Gateway.   If  no  ACK  byte  is received, the PC Gateway is
  67.      assumed to be unable to  handle  the  packet  right  now  and  a
  68.      timeout is said to have occurred.  The PC may either retry, wait
  69.      or return an error.
  70.      
  71.           After  the PC receives the ACK signal, it may begin sending
  72.      the packet.  The first four bytes of the packet  should  be  the
  73.      local  net header and an error will occur if they are not valid.
  74.      When the PC has completed sending the packet, it should send  an
  75.      END  byte to the Gateway.  The PC gateway will then consider the
  76.      packet and act upon it.
  77.  
  78.  
  79.  
  80.                                                                     2
  81.      
  82.      
  83.           The PC Gateway goes through a similar process when it sends
  84.      a packet to a PC; only the roles are reversed.  It is  an  error
  85.      for  the  PC  Gateway to send a PC its address if the PC has not
  86.      requested its address from the Gateway.
  87.      
  88.           If a machine should receive a REQ  embedded  in  a  packet,
  89.      this  indicates  that the END signal was dropped somewhere.  The
  90.      receiving machine should drop the packet it  was  receiving  and
  91.      begin to receive a new one.  ACKs may be mixed inside packets to
  92.      allow  immediate  response  to REQs.  The receipt of an ACK by a
  93.      machine should be duly logged (and perhaps appropriately ignored
  94.      if the PC doesn't have an outstanding request).
  95.      
  96.           The final code, ESC, is used to allow the characters  whose
  97.      codes  are  used  by ESC, REQ, ACK and END to appear in packets.
  98.      Receiving an ESC indicates that the next byte should  be  looked
  99.      at  to  produce  the  correct character.  Here is a table of the
  100.      codes for the signals and the ESC sequences to produce the  data
  101.      whose codes they use.
  102.      
  103.      ESC      242       ESC 0
  104.      REQ      243       ESC 1
  105.      ACK      244       ESC 2
  106.      END      245       ESC 3
  107.      
  108.           A  simple  way to unstuff the bytes is to add the character
  109.      following an ESC to the ESC to get the correct code and then put
  110.      it in the packet as data.  It is an error to have any  character
  111.      >3 follow an ESC.
  112.      
  113.           If  a machine receives any character other than a REQ or an
  114.      ACK when it is not in the process  of  receiving  a  packet,  it
  115.      should discard that character.
  116.      
  117.           Low-level  protocol  specification: IBM to Gateway, Gateway
  118.      to IBM.
  119.      
  120.           The following ASCII codes are used as flags in  the  manner
  121.      specified:
  122.      
  123.      242      - Prefix  code  for  sending  data  codes which are set
  124.                 aside for protocol use.
  125.      243      - Request to send (REQ).
  126.      244      - Acknowledge (ACK).
  127.      245      - End of packet (END).
  128.      
  129.           A typical data transfer occurs as follows:
  130.      
  131.      
  132.      IBM wants to send packet to Gateway:  It sends REQ and waits for ACK.
  133.      Gateway is ready to receive packet:   It sends ACK
  134.      IBM sends packet to Gateway followed by END.
  135.      The packet itself is encoded so that REQ,  ACK,  and  END  never
  136.      appear  in  the  text.  This is done by performing the following
  137.      substitutions:
  138.  
  139.  
  140.  
  141.                                                                     3
  142.      
  143.      
  144.      242 --> 242 0
  145.      243 --> 242 1
  146.      244 --> 242 2
  147.      245 --> 242 3
  148.      
  149.           Note  that  transfers  can   occur   in   both   directions
  150.      simultaneously.  However the ACK signal may be embedded within a
  151.      data packet and must be explicitly removed:
  152.     
  153.      IBM wants to send packet to Gateway:  It sends REQ and waits for ACK.
  154.      Gateway is ready to receive packet:   It sends ACK.
  155.      IBM starts sending packet.
  156.      Gateway wants to send packet to IBM:  It sends REQ and waits for ACK.
  157.      IBM is ready to receive packet:       It sends ACK.
  158.      IBM  continues  sending  its  packet, while Gateway sends a packet to
  159.      IBM.
  160.      
  161.           Timeouts may occur if the wait between a REQ and an ACK  is
  162.      too  long or no packet characters are transmitted for too long a
  163.      time.  In both cases no recovery action is undertaken: the other
  164.      system is assumed to have crashed.
  165.      
  166.           Receipt of protocol codes within  a  data  packet  has  the
  167.      following consequences:
  168.      
  169.      REQ      - End portion of data packet being sent has been lost.
  170.      ACK      - Should  be removed from input packet and its presence
  171.                 logged for  use  by  the  process  which  is  sending
  172.                 characters.
  173.      END      - Packet has been completely sent.
  174.  
  175. ================================================================
  176.  
  177. Dewayne Hendricks, WA8DZP          ! CIS: 75210,10    AppleLink: D6547
  178. Tetherless Access Ltd.             ! Packet Radio: WA8DZP @ K3MC.#NOCAL.CA
  179. 43730 Vista Del Mar                ! AOL: HENDRICKS 
  180. Fremont, CA 94539-6250             ! Internet: dewayne@netcom.com
  181.  
  182.  
  183.  
  184.